On-Premises Content Inspection GCP Deployment Procedure

This document outlines the GCP-specific setup procedure for Content Inspection on-premises deployment.

Customer Requirements

Infrastructure Prerequisites

• GKE cluster with minimum node specs (4 vCPUs, 16GB RAM per node)
• Working Ingress controller (GKE Ingress recommended)
• Permissions to create service accounts, IAM bindings, and GCS buckets

Required Tools

• gcloud CLI, kubectl, helm

Part 1: Customer Prerequisites

Complete these steps before contacting Cyberhaven for SaaS configuration.

1. Create Consolidated Service Account

Create a single service account for all CI stack components:

PROJECT_ID=$(gcloud config get-value project)
NAMESPACE="default"  # Adjust if deploying to different namespace

# Create consolidated service account for CI stack
SA_NAME="ci-stack"
SA_EMAIL="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

gcloud iam service-accounts create "${SA_NAME}" \
    --display-name="CI Stack Consolidated Service Account"

# Grant storage access for cache bucket
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/storage.objectViewer"

# Enable workload identity
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[${NAMESPACE}/${SA_NAME}]" \
    --role="roles/iam.workloadIdentityUser"

echo "Service Account: $SA_EMAIL"
echo "Project ID: $PROJECT_ID"

Note for Existing Deployments: If you already have a dlp-coordinator service account, you can reuse it as your consolidated CI stack service account instead of creating a new one. Simply use SA_NAME="dlp-coordinator" in the commands above.

2. Create Storage Bucket

CACHE_BUCKET="files-cache"
gcloud storage buckets create gs://$CACHE_BUCKET \
    --location=us-central1 \
    --uniform-bucket-level-access \
    --public-access-prevention \
    --default-storage-class=STANDARD

echo "Cache Bucket: $CACHE_BUCKET"

3. Verify Ingress Controller

Ensure your ingress controller is working. For GKE Ingress:

• GKE Ingress Documentation
• Test with a simple ingress resource

4. Custom Metrics Stackdriver Adapter (Optional)

This is optional but recommended for large-scale or spikey environments to optimize autoscaling:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml

# Create service account for custom metrics adapter
gcloud iam service-accounts create custom-metrics-sd-adapter \
    --description="Custom metrics Stackdriver adapter" \
    --display-name="custom-metrics-sd-adapter"

# Grant monitoring permissions
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:custom-metrics-sd-adapter@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/monitoring.viewer"

# Enable workload identity for adapter
gcloud iam service-accounts add-iam-policy-binding \
    "custom-metrics-sd-adapter@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/iam.workloadIdentityUser" \
    --member="serviceAccount:$PROJECT_ID.svc.id.goog[custom-metrics/custom-metrics-stackdriver-adapter]"

# Annotate adapter service account
kubectl annotate serviceaccount --namespace custom-metrics \
    custom-metrics-stackdriver-adapter \
    iam.gke.io/gcp-service-account=custom-metrics-sd-adapter@$PROJECT_ID.iam.gserviceaccount.com

echo "Custom Metrics SA: custom-metrics-sd-adapter@$PROJECT_ID.iam.gserviceaccount.com"

Verify the adapter pod is running:

kubectl get pods -n custom-metrics

Information to Share with Cyberhaven

Provide these values to Cyberhaven for SaaS configuration:

• Project ID: $PROJECT_ID
• Service Account Email: $SA_EMAIL
• Namespace: $NAMESPACE
• Custom Metrics SA (if using): custom-metrics-sd-adapter@$PROJECT_ID.iam.gserviceaccount.com

---

Part 2: Post-SaaS Configuration

Complete these steps after Cyberhaven grants your service account access to the SaaS GCP resources.

1. Configure Helm Values

Update values/customer-values.yaml with your GCP-specific settings:

global:
  customer:
    provider:
      type: "gcp"
      serviceAccount: "ci-stack@your-project.iam.gserviceaccount.com"  # or dlp-coordinator@... if reusing existing
    cache:
      type: "gcs"
      name: "files-cache"
    ingress:
      enabled: true
      className: "gce"  # or your preferred ingress class
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: "25m"
        nginx.ingress.kubernetes.io/proxy-read-timeout: "200"

Note: For GCP deployments, you do not need to configure global.customer.saas.googleCredentials as your service account has direct access.

2. Deploy

Follow the standard installation procedure from INSTALL.

Validation

After deployment, verify:

1. Pod Status: All pods reach Running state
2. GCS Access: CI components can read/write to cache bucket
3. SaaS Connectivity: Monitor for successful request processing
4. Custom Metrics (if enabled): Verify Stackdriver metrics are available

Troubleshooting

Workload Identity Issues: Verify service account IAM bindings and annotations GCS Access Denied: Check storage permissions and bucket configuration Ingress Issues: Verify ingress controller and firewall rules Missing Metrics: Check custom-metrics-stackdriver-adapter pod status

For issues, collect pod logs and run make status before contacting support.

Migration from Legacy Setup

If upgrading from previous versions with separate service accounts:

1. Option A (Recommended): Keep existing dlp-coordinator service account as your consolidated CI stack identity
2. Option B: Create new ci-stack service account and migrate permissions
3. Remove separate service accounts for dlp-tika, ci-scanner, and dlp-ocr (if they exist)
4. Update workload identity bindings to use the consolidated service account
5. Grant any missing permissions to the consolidated service account

This consolidation simplifies identity management while maintaining security.